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The  Intelligent  Maintenance  Training  System  (IMTS)  is  a  set  of 
software  tools  for  composing  and  delivering  simulation-based  technical 
training.  The  goal  in  developing  IMTS  was  to  generate  instructional 
interactions  from  device  models  composed  of  instances  of  generic  objects. 


Problem  selection  in  IMTS  relies  on  the  use  of  a  normative  model  that 
reflects  the  structure  of  the  target  device.  Proficiency  measures  are 
maintained  for  each  student  in  terms  of  this  model  and  support  the  selection 
of  problems  of  appropriate  difficulty  and  type. 


IMTS  incorporates  a  formulation  of  generic  diagnostic  expertise, 
termed  Profile,  that  1)  explains  the  significance  of  particular  test  outcomes 
and  remediates  student  beliefs  about  symptom  implications,  2)  recommends 
what  to  do  next,  taking  completed  tests  into  account,  3)  assesses  student 
proficiency,  and  4)  debriefs  the  student  following  each  fault  isolation 
exercise. 


A  number  of  findings  and  recommendations  are  listed.  The  next  steps 
for  IMTS  development  are  also  oudined,  including  techniques  for 
simulating  devices  whose  complete  functional  behaviors  cannot  reasonably 
be  specified  and  the  addition  of  features  to  support  procedural  training. 
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SECTION  I.  INTRODUCTION 


This  is  the  final  technical  report  covering  development  of  the  Intelligent 
Maintenance  Training  System  (IMTS)  developed  at  Behavioral  Technology 
Laboratories  over  the  past  three  years. 

The  IMTS  serves  three  purposes.  First,  it  is  a  demonstration  of  the  feasibility 
of  generating  device-specific  maintenance  instruction  from  generic  troubleshooting 
intelligence  applied  to  device  specifications.  Second,  it  provides  a  tool  for  the 
development  and  delivery  of  maintenance  training  for  such  applications  as  the  SH- 
3H  Helicopter  Bladefold  system  and  a  WSC-3  Satellite  Communications  System. 
Third,  it  provides  an  extendable  environment  for  further  research  on  a  variety  of 
topics,  including  the  application  of  direct  manipulation  methodologies  to  graphic 
simulation  composition;  the  effectiveness  of  generated  instruction  as  opposed  to 
authored  instruction;  and  appropriate  roles  for  interactive  graphics  in  technical 
training. 

The  Goal:  Maintenance  Instruction  Derived  from  Device  Models 

An  overriding  goal  in  the  development  of  IMTS  has  been  to  generate  device¬ 
specific  training  using  device-general  intelligence  applied  to  technical  specifications 
of  a  particular  device.  Of  course,  hand  tailored  instructional  materials  are  valuable 
and  even  necessary  in  many  contexts.  Still,  there  are  considerable  advantages  to 
generated  instruction.  Where  instruction  can  be  effectively  generated,  it  may  be 
possible  to  guarantee  greater  thoroughness,  completeness,  and  consistent  accuracy 
than  is  possible  with  purely  human-generated  instructional  materials.  Generated 
instruction  allows  meaningful  interactions  when  a  huge  number  of  situations  and 
requirements  could  be  encountered  and  allows  production  of  training  courseware  at 
a  reduced  cost,  in  comparison  to  manually  authored  instruction. 

Creating  instructional  interactions  at  run  time  based  on  a  device  description  has 
a  number  of  advantages,  both  for  the  student  and  for  those  who  must  develop, 
maintain,  and  administer  the  training  system.  Chief  among  the  advantages  for  the 
student  is  that  a  wide  range  of  interactions  are  possible.  This  makes  it  feasible  for 
students  to  control  many  of  the  surface  characteristics  of  their  interactions  with  the 


IMTS  tutor/advisor.  Students  can  utilize  options  of  a  data-driven  system  that  would 
not  be  feasible  in  a  system  in  which  all  the  interactions  are  pre-authored.  For 
example,  IMTS  students  can  insert  simulated  malfunctions  for  which  the  human 
author  has  prepared  no  instructional  materials  and  then  experiment  with  the 
simulated  device  exhibiting  that  failure  mode. 

For  the  developers  and  maintainers  of  a  technical  training  package,  there  are 
also  great  advantages  to  basing  training  on  a  device  model.  Many  different  kinds  of 
aiding  and  instructional  interchanges  can  be  delivered  to  the  student  without  having 
to  be  separately  authored.  If  the  target  device  is  modified,  the  corresponding 
change  can  be  made  to  the  description,  and  all  the  instructional  elements  related  to 
the  change  will  automatically  have  the  appropriate  form.  Similarly,  if  an  error  in 
the  expert  author's  understanding  of  the  device  description  is  detected,  it  can 
usually  be  repaired  with  a  simple  change  to  the  technical  specification. 

Our  objective  was  to  make  this  process  as  easy  as  possible.  The  IMTS 
development  system  consists  of  a  number  of  generalized  tools  for  describing 
devices  (a  "device",  as  used  here,  is  any  collection  of  component  pans).  Graphics 
editors  are  used  to  draw  the  components  of  a  device  and  position  them 
appropriately  in  scenes.  A  behavior  editor  is  used  to  describe  the  ways  in  which 
generic  objects  function  in  normal  and  failed  states.  Most  of  the  actual 
troubleshooting  advice  and  instruction  provided  to  the  student  is  created  at  run  time 
by  an  IMTS  generic  expert  module  that  has  access  to  the  device  description  and  to 
the  student's  diagnostic  performance. 

Approach 

One  key  to  the  generation  of  instruction  in  the  IMTS  is  the  separation  of  the 
generic  intelligence  required  to  instruct  corrective  maintenance  from  the  device¬ 
specific  technical  information  (knowledge)  that  characterizes  each  particular 
system.  The  generic  intelligence  built  into  the  IMTS  consists  of  1)  diagnostic 
expertise,  and  2)  instructional  expertise. 

Because  the  instructional  intelligence  is  provided  in  the  IM.TS,  it  is  possible  for 
technical  experts  to  supply  the  necessary  specifications  to  support  training  without 


also  requiring  instructional  expertise,  diagnostic  expertise,  or  programming  skills. 
The  drawback  of  the  approach  is  that  users  cannot  alter  the  instructional  strategy  or 
the  diagnostic  approach,  if  they  feel  that  these  could  be  improved  or  adapted  to 
better  meet  particular  requirements.  A  future  version  of  IMTS  may  incorporate 
tools  for  customizing  the  instructional  approach  and  the  diagnostic  strategy. 

We  now  briefly  describe  the  instructional  approach  and  diagnostic  strategy 
employed  in  the  IMTS. 

The  Instructional  Orientation 

The  IMTS  was  designed  to  provide  troubleshooting  practice  to  technicians 
already  trained  in  general  principles  (of  electronics  or  hydraulics)  and  already 
familiar  with  the  appearance,  organization,  and  function  of  the  device  they  are 
learning  to  maintain. 

Instruction  is  simulation-oriented,  i.e.,  the  student  learns  by  attempting  to 
perform  troubleshooting  tasks  on  a  simulation  of  the  target  device.  For  each 
exercise,  the  student  is  presented  with  a  failure  report  and  a  simulation  of  the 
device,  containing  a  failure  selected  by  the  training  system.  The  student  performs 
tests  and  replacements  on  the  simulation  until  he  or  she  claims  that  the  system  has 
been  restored  to  normal  operation.  When  necessary,  c '  upon  student  request, 
advice  and  commentary  about  the  student's  troubleshooting  actions  are  provided. 

The  IMTS  training  philosophy  is  built  upon  a  foundation  of  research  in 
intelligent  tutoring.  Twenty-one  principles  from  this  research  guided  the 
development  of  instructional  decisions  within  the  training  context.  In  brief,  these 
are  the  principles,  listed  with  the  research  studies  that  justify  them: 

1 .  Instruction  should  be  relevant  to  the  problem-solving  context. 

(Tulving,  1983;  Tulving  &  Thompson,  1973) 

2.  Provide  immediate  feedback  on  errors. 

(Bilodeau,  1969;  Skinner,  1958) 
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3.  Sustain  the  simulation  session  by  postponing  instructional  content  which  would 
obviate  the  motivation  for  the  session.  (Don't  give  it  all  away!) 

4.  Provide  quick  response. 

5.  Explicitly  identify  the  goal  structure  of  the  problem  domain. 

(Anderson,  Farrell,  &  Sauers,  1984) 

6.  Minimize  the  student's  working  memory  load. 

(McKendree,  Reiser,  &  Anderson  1984) 

7.  Prevent  superstitious  behavior. 

8.  Help  students  to  approach  target  skills  by  successive  approximations. 
(Anderson,  1983;  Anderson,  Farrell,  &  Sauers,  1984) 

9.  Protect  students  from  building  extended  chains  of  misconceptions. 

10.  Protect  students  from  negative  consequences  of  appropriate  actions. 

1 1 .  Instruct  opportunistically. 

12.  Maintain  the  credibility  of  the  tutor. 

The  remaining  principles  are  taken  from  (Burton  &  Brown,  1982). 

13.  Before  giving  advice,  be  sure  that  the  student  needs  it. 

14.  When  illustrating  an  issue,  use  an  example  for  which  the  correct  move  is 
dramatically  superior  to  the  move  made  by  the  student. 

15.  After  remediating,  give  the  student  an  opportunity  to  exercise  the  new 
knowledge. 

16.  If  the  student  is  about  to  fail,  interrupt  and  provide  moves  that  will  prevent 
failure. 

17.  Never  intervene  and  tutor  on  two  consecutive  student  moves. 

18.  Don't  prevent  student  discovery  by  overtutoring. 

19.  Intervene  on  exceptional  successes,  as  well  as  on  failures. 


20.  Always  have  the  artificial  expert  play  an  optimal  game. 

21.  Provide  help  in  several  layers. 

The  largely  non-invasive,  non-controlling  nature  of  the  IMTS  instructional 
system  can  be  attributed  to  adherence  to  many  of  these  principles.  A  student  who 
has  been  doing  fairly  well  in  a  problem  will  occasionally  perform  a  rather  poor 
test.  If  progress  has  been  generally  good  in  comparison  with  expert  performance, 
the  IMTS  will  remain  silent  and  let  the  student  continue.  In  this  respect,  IMTS 
behaves  much  like  many  human  tutors,  who  often  allow  students  to  continue  when 
their  behavior  is  not  optimal,  so  long  as  progress  is  being  made.  This  hands-off 
approach  gives  students  an  opportunity  to  practice  without  constant  interruption. 
Naturally,  performance  is  still  monitored  in  this  silent  mode,  and  aid  is  given  to 
help  students  avoid  long  unproductive  periods.  Further  discussion  of  these 
principles  can  be  found  in  an  earlier  report  (Towne,  Munro,  Pizzini,  Surmon,  and 
Johnson,  1985). 

Profile  —  a  Generic  Model  of  Diagnostic  Expertise 

Under  funding  from  the  Engineering  Psychology  program  of  the  Office  of 
Naval  Research,  BTL  developed  a  generic  expert  diagnostician  called  Profile 
(Towne,  Fehling,  &  Bond,  1981;  Towne,  1984;  1985;  1986)  and  conducted 
empirical  studies  of  its  troubleshooting  behavior  in  comparison  with  that  of  human 
experts  (Towne,  Johnson,  &  Corwin,  1982;  1983).  The  Profile  model  of  diagnostic 
expertise  is  the  foundation  for  a  number  of  different  research  efforts  at  Behavioral 
Technology  Laboratories  (Figure  1). 

Profile  can  be  applied  to  generated  fault  data  in  several  different  ways.  For 
example,  it  can  be  used  in  conjunction  with  a  commercial  computer-aided 
engineering  (CAE)  package  to  evaluate  designs  for  their  maintainability  (Towne  & 
Johnson,  1984;  1987).  In  the  research  reported  on  here,  Profile  is  used  to  generate 
intelligent  advice  and  commentary  on  troubleshooting  actions  made  on  a  simulated 
device. 
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Figure  1 .  Profile  Fills  Multiple  Roles 


Training  Configurations 

The  present  IMTS  has  been  implemented  on  Xerox  Artificial  Intelligence 
workstations,  including  the  models  1 108,  1186,  and  1132.  These  computers  are 
microcoded  for  Lisp,  and  they  offer  high  speed  graphical  displays  of  moderately 
high  resolution  (at  least  1024  x  800).  All  IMTS  development/authoring  tools, 
simulation  routines,  and  instructional  presentation  routines  were  written  in 
Interlisp-D,  a  Lisp  dialect  for  which  the  Xerox  machines  have  been  optimized. 

The  IMTS  is  designed  to  work  in  two  different  training  delivery  environments, 
either  1)  as  an  intelligent  adjunct  to  some  other  training  device,  such  as  a  high- 
fidelity  simulator,  or  2)  as  a  stand-alone  training  system. 
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Adjunct  Configuration 

When  IMTS  is  connected  to  an  external  simulator  that  adheres  to  the  IMTS 
communications  protocol,  students  can  interact  primarily  with  the  external 
simulator,  relying  on  the  IMTS  display  for  advice  and  ancillary  instruction.  The 
high-fidelity  simulator  involved  in  this  dual-mode  configuration  might  be  a  full- 
scale  mock-up,  a  computer-controlled  2-D  simulator,  or  just  a  videodisk  unit. 

At  present,  one  external  simulator,  the  Generalized  Maintenance  Trainer 
Simulator  (GMTS)  supports  this  communication  protocol.  GMTS  is  a 
microcomputer-based  surface-behavior  simulator  that  presents  color  images  stored 
on  videodisk  under  computer  control(Towne,  1986;  Munro,  Towne,  &  King,  1980; 
Towne  &  Munro,  1981;  Johnson,  Munro,  &  Towne,  1981).  Students  use  a  touch- 
sensitive  panel  on  the  external  monitor  to  change  controls  and  to  place  test 
equipment  probes  on  the  displayed  video  images. 

IMTS  supports  the  textual  communication  features  of  GMTS  by  providing  a 
window  that  acts  as  a  virtual  terminal  display  for  the  use  of  the  GMTS  software 
(Figure  2).  This  window  provides  a  25-line  by  80-character  screen  that  presents 
the  text  output  of  the  GMTS  computer,  replacing  the  ASCII  terminal  that  is  used 
with  GMTS  simulations  not  augmented  with  IMTS  instruction. 
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Figure  2.  A  Virtual  Terminal  Window  Under  the  Control  of  GMTS 


The  GMTS  simulator  has  no  built-in  instructional  capacities  when  it  is  used  in 
the  simulated  troubleshooting  mode  (it  does  provide  a  general-purpose 
instructional  function  as  a  separate  facility).  Communicating  over  an  RS232 
interface,  the  GMTS  informs  the  IMTS  of  every  action  that  the  student  takes.  The 
IMTS  recognizes  what  tests  are  being  performed,  and  it  evaluates  them  by  calling 
Profile.  Profile-based  evaluations  and  Profile-generated  suggestions  provide  the 
bulk  of  the  instructional  features  available  in  the  combined  IMTS-GMTS  mode. 


Figure  3.  Student  Interactions  in  the  IMTS/GMTS  Environment 

Students  can  interact  with  at  least  three  different  modules  in  the  integrated 
IMTS/GMTS  environment  (see  Figure  3):  1)  they  can  manipulate  and  observe  the 
functional  simulation  shown  on  the  IMTS  graphics  display,  2)  they  can  interact  with 
the  instruction  module  in  ways  that  will  be  described  below,  or  3)  they  can 
manipulate  and  observe  the  physical  surface  simulation  portrayed  by  the  GMTS 
using  videodisk  and  graphics  overlays. 

In  fact,  the  box  labeled  GMTS  in  the  above  Figure  is  not  constrained  to  be  a 
videodisk-based  simulator.  It  could  as  well  be  a  flat  panel  or  a  3-D  simulator  that 
has  a  computer  interface  that  can  communicate  with  IMTS  using  the  IMTS/GMTS 
communications  protocol.  Even  an  actual  device  could  conceivably  be  used,  so  long 
as  it  was  modified  so  that  it  would  report  all  user  actions  to  the  IMTS  using  the 
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IMTS  communications  protocol.  Viewed  this  way,  IMTS  is  an  intelligent  aiding 
station  that  can  be  used  with  any  of  a  variety  of  training  devices. 

Stand-alone  Configuration 

In  the  stand-alone  configuration,  currently  under  development,  the  IMTS  will 
perform  all  the  simulation  and  instruction  functions  without  a  mediating  GMTS 
computer  system,  as  shown  in  Figure  4. 


Functional 

Simulation 

Model 


Instruction 

Module 


lisSi 


Device  Model  ■ 

Surface 

Simulation 


Figure  4.  Student  Interactions  with  Stand-alone  IMTS 

In  this  environment,  the  surface  simulation  currently  provided  by  GMTS  may 
be  presented  graphically  on  the  IMTS  computer  display  or  may  be  displayed  using  a 
videodisk  under  the  direct  control  of  the  IMTS  computer. 

IMTS  Elements 

Regardless  of  the  configuration  (adjunct  or  stand-alone),  the  primary  elements 
in  the  IMTS  design  are  these: 

•  a  functional  model  of  the  device, 

•  graphical  representations  of  the  device,  functional  and/or  physical, 


i 


*-*V  VS**’  V  V  ‘ 


•  a  model  of  the  student. 
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•  generic  diagnostic  expertise, 

•  generic  instructional  expertise. 

Section  II  describes  techniques  for  producing  and  using  the  functional  device 
model,  including  graphical  representations  of  the  device;  Section  III  describes  the 
techniques  for  modeling  the  student  and  selecting  appropriate  problems;  Section  IV 
describes  the  IMTS  processes  for  monitoring  student  proficiency  and  progress,  and 
for  providing  appropriate  assistance;  and  Section  V  presents  conclusions. 
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SECTION  II.  MODELING  AND  REPRESENTING  THE  DEVICE 


Virtually  all  of  the  IMTS  instruction  is  derived  from  manipulations  of  a 
functional  model.  This  model  is  produced  automatically  when  the  functional  scenes 
are  composed,  i.e.,  underlying  the  graphical  representation  are  all  the  generic 
object  rules  and  connectivity  data  necessary  to  determine  the  behavior  of  the 
particular  device.  Interactions  with  the  student  may  be  based  either  on  the 
functional  representation  or  upon  a  physical  representation  that  is  created  in  terms 
of  the  functional  form.  We  first  discuss  the  functional  model  and  its  associated 
representation. 


The  Functional  Model 

The  functional  model  is  regarded  as  the  primary  medium  for  illustrating  and 
explaining  the  behaviors  of  the  target  system.  The  model  is  represented  to  the 
student  via  computer  graphic  drawings  that  respond  to  the  effects  of  the  student's 
actions  and  to  inserted  failures.  The  first  device  we  have  modeled  in  this  fashion  is 
a  complex  helicopter  bladefolding  system  in  which  the  components  are  organized  as 
thirteen  interrelated  schematic  'diagrams',  or  scenes.  Figure  5  shows  a  portion  of  a 
representative  scene  from  the  Bladefold  simulation  set. 


The  student  changes  the  setting  of  a  control  by  selecting  the  desired  new  position 
with  the  mouse  (all  references  to  'selecting'  imply  that  the  user  positions  the  mouse 
cursor  on  the  desired  object  or  menu  item  and  clicks  the  mouse  button).  The 
simulation  is  then  updated,  i.e.,  all  effects  of  the  switch  change  are  determined, 
including  effects  that  are  off  screen  (on  other  scenes).  This  complete  evaluation  is 
necessary,  since  effects  on  the  currently  displayed  scene  may  be  caused  by  changes 
in  portions  of  the  simulation  not  in  view  (which  were  in  turn  caused  by  the  switch 
change  accomplished  on  screen).  The  currently  displayed  scene  is  then  updated  by 
displaying  all  new  object  states,  including  the  switch  that  was  changed.  Because  the 
non-dynamic  background  elements  in  the  scene  are  not  redisplayed,  the  user  sees 
the  changes  in  object  states  without  visual  disruption. 
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Figure  5.  A  Scene  from  the  IMTS  Bladefold  Graphical  Simulation 

The  total  time  to  update  the  thirteen-scene  Bladefold  simulation,  in  response  to  a 
student  action,  is  now  approximately  four  seconds.  This  response  time  was  attained 
only  after  extensive  experimentation,  analysis,  and  modification  of  alternative 
simulation  algorithms. 


The  student  can  also  observe  the  value  at  a  test  point  by  selecting  the 
graphical  object  representing  the  test  equipment  to  be  used,  and  then  selecting  the 
test  point,  as  displayed  on  the  functional  diagram.  The  test  equipments  currently 
provided  are  a  multimeter,  oscilloscope,  and  pressure  gauge.  Course  developers 
can  add  new  test  equipments  by  defining  them  graphically  and  functionally,  using 
the  standard  IMTS  object  authoring  system,  described  below. 


The  simulation  can  represent  a  normally  operating  system,  or  one  with  one 
or  more  failures  present.  If  there  are  failures  present,  they  can  either  be  known  to 


the  student  or  they  may  be  of  unknown  character,  to  be  determined  by  the  student  s 
diagnostic  actions.  Students  can  replace  simulated  objects  with  ones  known  to  be 
good.  Upon  replacing  the  malfunctioning  component,  the  student  will  observe 
entirely  normal  test  results  (if  there  was  only  one  failure  present). 

Students  move  through  the  scenes  of  a  complex  simulation  by  using  a 
hierarchical  map  of  the  functional  subsystems  of  the  device.  The  map  (Figure  6)  is 
always  on  display,  in  the  upper  left  portion  of  the  screen.  To  bring  a  particular 
scene  into  the  main  scene  window,  the  student  selects  the  corresponding  terminal 
node  in  the  map. 
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Figure  6.  The  Scenes  Hierarchy  and  Special  Objects  Panels 

Students  or  instructors  can  create  an  ad  hoc  scene  containing  objects  of 
particular  interest  at  any  time  by  selecting  the  objects  from  their  main  scenes  and 
copying  them  into  the  gray  panel  at  the  left  of  the  main  scene  window.  The  objects 
in  this  scratch  area  can  be  manipulated  exactly  as  are  the  originals,  and  they  respond 
graphically  to  all  student  actions  made  either  on  the  ad  hoc  scene  or  upon  the  main 
scenes.  This  feature  also  facilitates  the  demonstration  and  examination  of 
interactions  of  objects  that  belong  to  different  scenes. 
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Authoring  the  Functional  Model 

This  section  will  briefly  outline  the  simulation  construction  process  within  the 
IMTS.  A  more  thorough  description  of  the  IMTS  simulation  composition  system  is 
presented  in  Towne,  Munro,  Pizzini  &  Surmon  (1987). 

Authors  build  graphical  simulations  using  a  series  of  four  editors.  A 
graphical  editor  is  used  to  draw  new  types  of  components,  whenever  the  required 
component  type  is  not  already  present  in  a  library.  After  drawing  a  component,  a 
behavior  editor  is  used  to  specify  how  a  component  operates,  and  how  it  can  be 
connected  to  other  components. 

The  scene  editor  is  used  to  create  and  to  connect  instances  of  the  generic 
component  types  (an  instance  of  an  object  is  'created'  by  simply  selecting  a  generic 
object  type  from  the  library  and  assigning  the  object  a  more  specific  name). 

Finally,  a  scene  connection  editor  is  used  to  indicate  how  the  scenes  of  simulation 
are  interconnected.  The  scene  connection  editor  also  creates  links  between  the 
elements  of  the  scene  map  and  the  actual  scenes  that  are  accessed  by  clicking  on 
those  elements. 

The  graphical  object  editor  and  the  object  behavior  editor  are  currently  being 
merged  into  one  integrated  object  creation  editor.  Likewise,  the  scene  editor  and 
scene  connection  editor  are  being  merged  into  a  single  multi-scene  simulation 
creation  editor. 

In  some  important  respects  the  process  of  creating  IMTS  simulations  is 
similar  to  that  used  in  STEAMER  (Hollan,  1983;  Hollan,  Hutchins,  &  Weitzman, 
1984),  which  also  makes  use  of  graphical  editors  for  objects.  A  crucial  difference 
between  the  two  approaches  is  that  in  IMTS,  system  level  behaviors  are  derived 
from  object  behaviors,  whereas  in  STEAMER  the  simulation  is  produced  via 
conventional  computer  programming  techniques,  and  the  generic  objects  portray 
values  within  the  simulated  system. 

The  Object  Graphics  Editor.  The  object  graphics  editor  allows 
construction  of  objects  using  graphical  primitives  such  as  line  segments,  rectangles, 


R 


ovals,  and  text  elements.  Figure  7  illustrates  the  editor  in  use,  expanding  a  library 
containing  functional  representations  of  objects.  Each  object  shown  is 
fundamentally  unique,  although  some  may  appear  similar.  Additionally,  most  of 
the  objects  are  multi-state  devices,  although  each  is  shown  in  only  one  graphic  state 
in  Figure  7.  The  toggle  switch  in  the  upper  left-hand  comer,  for  example,  is  shown 
in  the  Up  position.  The  switch  below  it  is  also  a  two-state  switch,  but  differs  in  the 
number  of  poles  available. 


Figure  7.  A  Library  of  Functional  Object  Graphics 

The  Object  Behavior  Editor.  The  object  behavior  editor  is  used  to  describe 
how  a  component  operates  in  each  state.  In  this  editor,  the  user  enters  rules  that 
state  the  conditions  under  which  the  object  will  take  on  each  state  and  what  output 
values  it  will  propagate  to  the  outside  world,  as  a  function  of  its  inputs.  The  state- 
rules  for  an  object  may  be  functions  of  the  previous  state  of  the  object,  values  of  its 
inputs,  and  relations  among  its  inputs  (such  as  input  x  >  input  y). 


Figure  8.  The  Behavior  Editor  in  Use 


The  behavior  editor  automatically  generates  Lisp  code  for  the  user-supplied 
behavior  rules,  compiles  the  code,  and  adds  the  resulting  function  to  the  object 
library.  The  IMTS  simulation  driver  routine  executes  these  compiled  routines 
during  training  to  maintain  an  accurate  graphical  representation  in  response  to  the 
student’s  actions. 

The  Simulation  Editor.  The  graphic  scenes  representing  sections  of  the 
real  device  are  composed  using  the  simulation  editor.  Authors  select  generic 
component  types  from  the  libraries  and  position  them  on  the  screen,  as  shown  in 
Figure  5.  When  a  new  component  is  juxtaposed  to  another,  adjoining  ports  are 
automatically  connected,  i.e.,  outputs  from  one  component  are  automatically 
recorded  as  flowing  to  the  input  of  the  other.  The  simulation  scenes  can  be 
arbitrarily  complex. 
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The  Scene  Composition  Editor.  After  producing  the  individual  scenes,  the 
simulation  developer  creates  a  map  of  the  scenes,  previously  shown  in  Figure  6. 

The  Physical  Model 

The  primary  vehicle  operated  upon  by  the  student  to  practice  diagnostic  actions 
is  the  physical  representation  of  the  target  system. 

Adjunct  Configuration 

In  the  adjunct  configuration  the  physical  representation  is  provided  in  the  form 
of  videodisk  images.  A  touch  panel  mounted  over  the  videodisk  screen  allows  the 
student  to  change  a  switch  setting  by  touching  the  desired  new  position.  Likewise,  a 
test  point  may  be  read,  after  selecting  a  test  equipment,  by  touching  a  displayed  test 
point  and  observing  the  resulting  display  of  the  test  equipment  face.  The  responses 
of  the  target  device  are  computed  by  GMTS,  employing  its  condition-evaluation 
technique  (a  rule-based  form),  rather  than  the  device  model  approach. 

Stand-alone  Configuration 

In  the  stand-alone  configuration,  the  IMTS  functional  model  is  used  to 
determine  system  behaviors,  and  both  the  functional  and  the  physical 
representations  are  updated  to  reflect  these  computed  responses.  In  this 
configuration  the  physical  model  may  be  represented  with  either  videodisk  images 
or  computer  graphic  images.  The  graphic  form  of  physical  objects  is  created  using 
the  object  graphic  editor  as  shown  in  Figure  9. 

The  graphic  views  of  front  panels  and  other  hardware  sections  are  created  by 
building  scenes  in  which  the  physical  objects  are  simply  tied,  or  slaved,  to  their 
counterparts  in  the  functional  scenes.  The  slaved  physical  objects  therefore  react 
correctly  by  simply  referring  to  the  underlying  functional  model.  A  physical  scene 
can  therefore  be  constructed  in  which  the  objects  appear  to  be  connected  to  each 
other,  but  in  fact  these  apparent  connections  are  not  involved  in  determining  system 
behavior. 


Figure  9.  Objects  in  a  Physical  Representation 


Links  Between  the  Physical  and  Functional  Representations 

An  important  concern  in  designing  the  IMTS  was  providing  linkages  between 
the  physical  and  functional  representations,  so  that  students  would  experience 
frequent  and  memorable  exposures  relating  the  two.  The  intention  is  to  promote 
the  student's  ability  to  find,  recognize,  and  manipulate  physical  elements  in  the  real 
system,  while  maintaining  a  conception  of  the  functional  relationships  that  cannot 
be  seen  directly  in  the  real  system. 

The  techniques  to  do  this  involve  1)  providing  both  physical  and  functional 
representations  of  the  system  so  that  students  can  examine  equivalent  views  either 
sequentially  or  simultaneously,  and  2)  providing  both  physical  and  functional  views 
of  single  objects. 
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Physical  and  Functional  System  Representations.  Because  physical 
objects  are  linked  to  their  functional  counterparts,  for  the  purpose  of  supporting  the 
physical  simulation,  the  IMTS  will  be  able  to  automatically  alternate  between  the 
two,  at  the  request  of  the  student.  Additionally,  the  videodisk  representation  can 
follow  along  automatically  as  the  student  operates  in  the  functional  form.  Of  course 
functional  organization  is  not  likely  to  correspond  with  physical  structure, 
therefore  the  physical  scene  corresponding  to  one  functional  object  might  be 
different  than  that  of  a  neighbor  object,  and  vice  versa. 

Physical  and  Functional  Views  of  Individual  Objects.  To  strengthen 
the  student's  understanding  of  physical  and  functional  equivalence,  the  IMTS  can 
display  'pictures'  of  individual  objects  within  their  functional  context.  In  Figure  10 
the  student  was  viewing  a  functional  scene  and  was  curious  about  the  appearance  of 
the  #1  Damper  Positioner  (near  the  upper  left).  Upon  requesting  a  pictorial  view  of 
the  part,  the  student  sees  the  presentation  shown. 
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Figure  10.  Bladefold  Scene  with  a  Digitized  Picture 
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SECTION  III.  Problem  Selection  and  Student  Modeling 


In  the  current  IMTS,  the  student  model  is  used  primarily  for  the  automatic 
selection  of  appropriate  problems  for  individual  students.  In  future  versions  the 
current  state  of  the  student  model  may  play  a  role  in  determining  other  aspects  of 
instruction  and  aiding,  such  as  frequency  of  intervening. 

Normative  Student  Modeling 

IMTS  uses  an  expert,  or  normative,  model  to  represent  device  understanding 
for  diagnostic  functions.  This  hierarchical  model  of  domain  knowledge  is  created 
by  the  device  expert,  and  used  as  the  default  model  of  each  individual  student.  As 
the  student  performs  troubleshooting  problems,  the  node  weights  of  the  model  are 
adjusted  based  on  the  quality  of  the  problem  solving  work.  This  approach  is  loosely 
based  on  the  student  modeling  mechanism  employed  in  BIP  (Wescourt,  Beard,  & 
Gould,  1977;  Wescourt  &  Hemphill,  1978;  Wescourt,  Beard,  Gould,  &  Barr,  1977; 
Beard,  Barr,  Gould,  &  Wescourt,  1978)  in  which  a  model  of  student  knowledge  and 
skill  was  based  on  a  component  analysis  of  the  content  of  a  curriculum.  The 
curriculum  content  was  represented  as  a  set  of  elementary  concepts  and  skills.  Each 
instructional  exercise  or  problem  was  considered  diagnostic  for  a  particular  subset 
of  these  concepts  and  skills.  Student  performance  on  the  problems  was  used  to 
modify  a  student-specific  model  of  knowledge  in  the  domain. 

The  model  has  the  form  of  a  tree  in  which  each  node  represents  the  knowledge 
about  some  aspect  of  the  equipment.  The  highest  nodes  in  the  tree  represent  the 
most  abstract  knowledge  about  the  global  functions  of  the  equipment.  The  nodes 
immediately  below  that  represent  top-level  knowledge  about  the  major  subsystems. 
Lower  nodes  represent  more  specific  skills  and  knowledge  about  modules  and 
components.  The  terminal  nodes  in  the  knowledge  tree  represent  knowledge  about 
specific  component  modes,  including  different  possible  types  of  component 
failures. 

The  model  is  linked  closely  to  the  structure  of  the  device  being  simulated. 
This  has  the  advantage  of  making  the  creation  of  such  models  fairly 
straightforward,  and  offers  the  potential  for  making  the  normative  modeling 
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process  automatic.  A  disadvantage  is  that  generic  kinds  of  knowledge,  such  as 
Ohm's  law,  are  not  easily  represented  in  such  an  equipment-specific  knowledge 
model. 

Creating  the  Normative  Model 

The  normative  knowledge  tree  is  built  using  the  IMTS  knowledge  network 
editor  (see  Figure  1 1).  The  current  implementation  of  the  Knowledge  Network 
Editor  makes  very  few  assumptions  about  the  structure  of  knowledge  in  device 
domains.  (Enhancing  the  editor  to  capitalize  on  domain-specific  features  is  a  likely 
topic  for  future  research  and  development  efforts.)  Providing  structure  is  the  task 
of  the  knowledge  network  author.  One  assumption  of  the  Editor  is  that  device 
knowledge  can  be  represented  in  a  simple  tree  structure.  Less  specific,  more  global 
information  is  represented  by  nodes  near  the  top  or  root  of  the  tree.  Detailed 
information,  such  as  the  particular  failure  modes  of  particular  elements  in  the 
device,  are  represented  by  nodes  at  the  bottom  of  the  tree. 

Maintaining  an  Individual  Student  Model.  The  understanding  of 
individual  students  is  represented  by  a  set  of  weights  for  the  nodes  of  the  tree. 

These  weights  represent  how  well  the  student  understands  the  corresponding 
portions  or  functional  subsystems  of  the  device. 

When  a  student  finishes  a  problem,  a  measure  of  his  or  her  performance  for 
that  problem  is  computed  to  modify  the  student  model.  The  node  that  corresponds 
to  the  actual  malfunction  is  directly  assigned  the  value  of  the  performance  measure. 
Each  of  the  ancestor  nodes  for  that  node  is  also  modified  to  reflect  the  performance 
as  well.  The  immediate  parent  is  modified  in  the  direction  of  the  performance  by 
an  amount  weighted  by  the  number  of  child  nodes  that  it  has.  Its  parent  node  is 
similarly  modified  by  an  amount  relative  to  the  extent  of  the  change  in  that  node, 
and  so  on  up  the  ancestor  tree.  A  change  in  a  single  specific  malfunction  node  can 
have  a  (usually  small)  effect  even  on  the  top  level  node,  which  represents  the 
student's  understanding  of  the  whole  system. 


Name 

Parent 

Children 

Instructional  Element 
Default  Mastery 


Common  System  Components 
3 

(5  6  7) 

0 

NewElement 
EditElement 
DeleteElement 
Togg  I  eProb  lem  S  ta  tus 
DiagramElement 
FullTree 
Quit 


!  Complete  Simplified  Biaoef old  Sys 

2  Simplif  Biadefoid  Hydraulics 

3  System  Controls,  Hydraulics 

4  Common  System  Components 

5  Specif  ic  Blade  Components 

6  Control  Pressure  to  System 

7  Select  Extend  or  Retract 

8  Move  Blade  to  Lead 

9  Lock  Flight  Control 

10  Extend  Blade  . 
i  i  Seauence  Events 

12  Seauence  Positioning 
J.3  Sequence  Locking 
i  4  Main  Press  Safety  Valve  (Ru  I ) 

15  Extend/Retract  Selector  (RU2) 


|  Local  'graph  of  (he  Knowledge  Bundle  1  ree  . 

: 

Select  Extend  or  Retract 
s  Control  Pressure  to  System 

Specific  Blade  Components 

Figure  11.  The  Knowledge  Network  Editor 


Problem  Selection 


Problem  selection  is  made  on  an  individual  basis,  using  the  proficiency 
records  for  the  student,  as  encoded  in  the  student  model,  and  the  global  measures  of 
student  ability  and  cognitive  style.  Proficiency  is  measured  by  normalized  time  to 
solve  the  previous  problem  and  on  average  test  power  for  the  exercise.  The  model 
is  updated  at  the  conclusion  of  each  problem,  to  support  the  selection  of  appropriate 
subsequent  problems  for  students. 


The  problem  selection  process  relies  on  two  measures  taken  from  the 
knowledge  structure:  conceptual  distance  and  conceptual  difficulty.  Conceptual 
distance  is  a  simple  measure  of  how  related  two  problems  are  in  terms  of  the 
domain  representation.  The  conceptual  distance  between  two  problem  nodes  is  the 
number  of  node  links  that  must  be  traversed  in  the  knowledge  element  hierarchy  to 
find  one  node  from  another,  weighted  by  the  student’s  current  mastery  levels  for 
the  intervening  nodes.  Conceptual  difficulty  is  the  value  of  the  "Problem 
Difficulty"  field  created  by  the  instructor. 

To  select  a  new  problem,  the  remaining  troubleshooting  exercises  are  evaluated 
for  their  conceptual  distances  from  the  last  problem  and  their  difficulty.  An  ideal 
conceptual  step  size  and  an  ideal  difficulty  for  the  next  problem  are  then  computed 
for  the  student.  The  desired  conceptual  step  size  is  a  function  of  the  student’s 
estimated  learning  speed  (which  is  based  on  prior  performance  and  an  instructor 
estimate),  a  student-controlled  value  that  expresses  how  large  a  conceptual  jump 
the  student  likes  to  make,  and  the  student's  performance  on  the  last  problem. 

•  If  the  student  has  a  high  learning  speed,  conceptual  distance  can  be 
larger. 

•  If  the  student  prefers  larger  conceptual  steps,  the  conceptual  distance 
can  be  larger. 

•  If  the  student  did  well  on  the  last  problem,  the  conceptual  distance  can 
be  larger.  (If  the  student  did  poorly  on  the  last  problem,  a  related  one 
is  called  for.) 

•  The  ideal  difficulty  level  for  the  student  is  a  function  of  the  student's 
learning  speed. 

It  is  rare  that  the  ideal  conceptual  distance  metric  and  the  ideal  difficulty 
metric  pick  the  same  problems.  A  weighting  scheme  combines  these  factors. 

Dimensions  of  Troubleshooting  Problem  Difficulty 

One  of  the  goals  of  simulation  training  is  to  provide  practice  at  an 
appropriate  level  of  difficulty.  If  students  are  presented  with  problems  that  are  too 
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easy,  they  will  simply  reapply  old  skills  and  learn  nothing  new.  On  the  other  hand, 
if  problems  are  too  difficult,  students  may  become  discouraged  and  fail  to  learn. 

To  a  large  extent,  the  difficulty  of  a  troubleshooting  problem  depends  on  the 
idiosyncratic  knowledge  of  a  student.  One  student  of  a  helicopter  bladefolding 
system  may  be  very  familiar  with  the  hydraulic  components  responsible  for 
positioning  the  No.  1  blade,  while  another  is  more  cognizant  of  the  subsystems 
related  to  the  rotor  brake.  These  two  students  would  not  order  a  set  of  problems 
for  difficulty  in  the  same  way. 

The  major  components  of  problem  difficulty  in  IMTS  include 

•  the  size  of  the  initial  suspicion  set 

•  the  level  of  representation  required  to  discriminate  the  fault 

•  the  knowledge  of  detailed  component  behavior  required 

•  the  remoteness  of  symptoms  from  the  suspected  faults 

IMTS  offers  several  means  of  presenting  a  fault  isolation  exercise  so  as  to 
reduce  or  increase  its  difficulty.  These  means  include  managing  the  instructional 
and  aiding  features  described  in  Section  IV.  In  addition,  it  is  possible  to  manipulate 
the  complexity  of  the  device  representation. 

Controlling  the  Complexity  of  the  Representation.  Using  the  same 
approach  employed  for  constructing  physical  representations,  simulation 
developers  may  create  alternate  forms  of  representations  in  which  the  objects  are 
simply  slaved  to  the  fully  detailed  functional  model.  As  a  result,  highly  simplified 
diagrams  can  be  produced  that  still  exhibit  accurate  behaviors.  For  students  who 
are  unfamiliar  with  the  helicopter  bladefold  system,  for  example,  a  simplified 
simulation  can  be  constructed  showing  only  one  blade  and  omitting  auxiliary  parts 
that  are  not  central  to  the  operation  of  the  device.  The  simplified  forms  may  be 
either  functional  or  physical. 


While  the  problem  selection  process  does  not  yet  consider  moving  to  problems 
in  alternative  representations,  it  will  be  enhanced  to  do  so  when  the  complete 
authoring  capabilities  have  been  completed. 
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SECTION  IV.  IMBEDDED  GENERIC  EXPERTISE 

Two  kinds  of  generic  expertise  are  imbedded  in  IMTS,  1)  diagnostic  expertise 
and  2)  instructional  expertise.  The  diagnostic  expertise,  in  the  form  of  the  Profile 
fault-isolation  process,  is  called  frequently  to  assess  the  student's  work  and  to 
provide  technical  advice  and  explanations.  The  instructional  strategy  is  embodied 
in  executive  routines  that  continually  assess  student  progress  and  call  on  the 
specialized  functions  to  respond  to  the  student's  needs.  We  first  describe  the 
generic  diagnostic  expert  model. 

Diagnostic  Expertise  from  Device  Data 

An  important  goal  of  the  IMTS  was  to  generate  the  diagnostic  intelligence  for 
a  particular  device  from  the  same  functional  model  that  supports  the  graphical 
representation.  This  leads  to  high  efficiency  of  course  development,  and  it  ensures 
that  the  diagnostic  expert  and  the  student  operate  upon  the  same  system  model.  As  a 
result,  all  diagnostic  advice  provided  can  be  explicitly  rationalized  to  the  student. 

To  identify,  justify,  and  interpret  a  good  next  test,  Profile  requires  data 
specifying  the  significance  of  each  possible  symptom  for  each  possible  test,  in  each 
mode  of  interest  (a  mode  is  a  combination  of  switch  settings).  This  is  turn  requires 
that  the  device  be  simulated  in  each  failure  condition  to  determine  what  symptoms 
are  produced  in  each  specified  mode.  Because  this  involves  considerable  compute 
time,  the  computation  of  symptoms  is  done  during  the  development  phase,  and  the 
results  are  stored  in  a  data  file  for  quick  access  during  training. 

The  utility  program  that  produces  the  symptom  data  inserts  a  failure  into  the 
device  model,  it  runs  the  IMTS  simulation  program  in  all  the  modes  of  interest,  as 
specified  by  the  course  developer,  and  it  records  the  results  at  each  indicator  and 
test  point.  By  comparing  each  result  to  that  obtained  with  no  failure  inserted,  the 
program  can  identify  all  abnormal  symptoms  resulting  from  the  failure.  This 
process  is  repeated  for  each  possible  failure. 

While  the  resulting  data  file  is  large,  only  limited  portions  are  accessed  for  any 
one  practice  problem.  The  complaint-specific  data  are  read  in  at  the  beginning  of 
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each  problem,  and  remain  accessible  throughout  the  problem.  When  Profile  is 
called  upon  to  suggest  a  test  early  in  a  problem,  when  there  are  many  alternative 
tests  and  suspected  elements,  it  requires  between  five  to  ten  seconds  to  complete  its 
analysis  of  the  alternatives.  If  the  student  has  performed  even  one  or  two  useful 
tests,  the  Profile  compute  time  drops  off  rapidly  to  just  a  few  seconds. 

Required  Human  Expertise 

As  mentioned  above,  human  intelligence  is  required  to  specify  the  modes  to  be 
considered  in  computing  fault  effects.  To  not  constrain  this  variable  would  lead  to 
impossible  data  file  sizes  and  compute  times.  The  training  implication  of  this 
restriction  is  that  the  IMTS  can  only  monitor  and  advise  the  student  as  long  as  he  or 
she  works  in  one  of  the  recognized  modes.  Preliminary  experience  indicates  that 
this  limitation  is  not  particularly  distressing,  as  each  problem  has  a  natural  and 
relatively  limited  set  of  modes  appropriate  for  fault  diagnosis. 

Human  knowledge  is  required  to  provide  a  second  element,  a  failure  report  for 
each  practice  problem  that  states  the  general  nature  of  the  problem  as  it  would  be 
reported  by  the  equipment  operator.  These  statements  typically  list  one  or  more 
high-level  system  functions  that  do  not  operate  normally,  and  some  conditions,  such 
as  the  mode,  under  which  the  abnormality  was  observed. 

The  failure  report  is  displayed  at  the  beginning  of  each  problem,  and  may  range 
from  highly  informative  to  quite  vague.  The  course  developer  has  the  option  of 
issuing  the  same  failure  under  different  failure  reports,  thereby  varying  the 
difficulty  of  the  problem. 


Fold  Power  On  Light  does  not  come  on  when  Master  Switch 
is  placed  On.  The  system  Is  in  Accessory  Drive  with  blades 
spread.  In  order  to  carry  out  tests  for  thrs  complaint:  1. 
Ensure  that  the  Safely  Valve  Switch  Is  "OPEN."  2.  Ensure 
that  the  Master  Switch  is  On.  3.  Ensure  that  the  Pylon  is 
spread  and  locked. 


Figure  12.  An  Initial  Failure  Report 
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Options  for  Adding  Human  Knowledge 

There  are  two  options  for  enhancing  each  practice  problem  by  adding  human 
knowledge,  1)  a  hint  to  help  the  student  get  started  on  the  problem,  and  2)  a 
technical  summary  that  explains  the  physical  (electronic,  hydraulic,  etc.) 
mechanisms  of  each  practice  failure.  Each  of  these  may  be  extensive,  brief,  or 
omitted  entirely. 

Problem  Hint.  If  provided,  the  hint  is  automatically  presented  if  a  student 
is  foundering  early  in  the  problem  and  has  not  requested  assistance  from  the  IMTS. 
The  hint  is  associated  with  the  failure  report,  thus  one  hint  may  support 
presentation  of  many  problems. 

K107  must  be  energized  to  have  power  to  the  Spread/Fold 
circuit. 

Figure  13.  A  P re- Authored  Hint 


Failure  summary.  If  available,  the  failure  summary  is  presented  upon 
completion  of  a  problem  to  more  fully  explain  why  and  how  the  symptoms  were 
produced.  Although  the  simulation  routine  generated  the  symptoms,  by  applying 
and  propagating  each  object's  behavior  rules,  human-supplied  explanations  provide 
the  most  rich  and  meaningful  account  of  the  technical  nature  and  consequences  of 
the  simulated  failure.  A  typical  failure  summary  is  shown  in  Figure  14. 


In  order  for  the  safety  valve  motor  to  operate,  relay  K102  must  energize, 
closing  contact  B1  to  B2.  Contact  B2  receives  its  24VDC  directly  from  the 
safety  valve  switch.  The  Safety  Valve  light  also  receives  its  24VDC  from  the 
switch.  Therefore,  with  K1 02  B2  shorted  to  B3,  the  light  can  go  on,  but  the 
motor  will  not  operate. 


Figure  14.  A  Failure  Summary 


Generic  Instructional  Expertise 

Students  have  partial  control  of  the  aiding  features  described  below.  These 
instructional  options  will  be  presented  automatically  to  students  who  need  them, 
but,  in  addition,  they  can  be  requested  by  students. 

Several  types  of  help  are  available,  in  addition  to  the  simple  hints  mentioned 
above.  The  help  functions  range  in  purpose  from  discussing  a  single  symptom  to 
direct  instructions  about  what  course  of  action  to  follow  next.  These  levels  of 
aiding  make  it  possible  to  help  a  student  while  still  preserving  some  potential  for 
student  discovery.  Those  students  who  cannot  make  it  through  a  difficult 
troubleshooting  problem  on  their  own  can  still  solve,  and  learn  from,  a  problem 
through  the  use  of  the  more  directed  aiding  features.  (Currently,  the  student  model 
does  not  take  the  degree  of  assistance  provided  into  account  when  updating  the 
student's  proficiency;  this  will  be  incorporated  in  the  future.) 

The  IMTS  uses  four  different  styles  of  aiding  and  instructing  the  student,  all 
based  on  the  generic  troubleshooting  expertise  of  Profile  in  exploring  and  applying 
the  fault  effect  data. 

Within-problem  Monitoring  and  Assistance 

Student  performance  is  monitored  within  problems  to  determine  what  help 
or  instruction  is  required  to  minimize  unproductive  time  and  to  help  ensure  success 
on  the  problem.  Two  major  elements  of  the  student's  performance  are  tracked 
within  a  problem:  time  on  the  problem  and  average  test  power  per  unit  of  time  on 
the  problem.  The  measure  of  time  spent  on  a  problem  is  a  relative  one;  time  on  the 
troubleshooting  problem  is  compared  with  a  parameter  that  compensates  for  the 
difficulty  of  that  problem.  The  average  test  power  measure  is  more  interesting. 
Profile  determines  the  relative  power  of  each  test  performed  by  a  student  by 
comparing  it  to  the  one  Profile  would  have  performed  at  that  point.  The  average  of 
these  values  provides  a  good  assessment  of  a  student's  diagnostic  performance  on  a 
problem. 
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Parameters  ranging  from  zero  to  one  may  be  entered  by  an  instructor  in 
order  to  specify  the  degree  to  which  students  may  deviate  from  ideal  performance 
before  receiving  assistance.  Four  different  test  power  parameters  can  be  set.  The 
first  of  these  determines  at  what  test  power  threshold  the  student  will  be  offered 
instructional  help  for  the  first  time.  A  second  parameter  determines  at  what 
threshold  subsequent  offers  of  help  will  be  made.  The  third  parameter  sets  the  test 
power  value  at  which  assistance  will  be  given  whether  the  student  wants  it  or  not, 
and  the  fourth  prescribes  the  test  power  level  for  subsequent  enforced  assistances. 

A  value  of  0.5  permits  significant  departures  from  maximum  test  power  before 
overt  aiding  or  instructional  features  are  brought  into  play. 

A  prime  objective  of  IMTS  is  to  operate  in  an  unobtrusive  manner,  allowing  the 
student  to  practice  fault  isolation  in  a  more  realistic  context  than  one  in  which 
advice  continually  intrudes  on  the  troubleshooting  process.  The  IMTS  remains 
largely  invisible  to  the  student  until  the  student  requests  aid  or  until  the  monitoring 
process  reveals  that  the  student  is  having  difficulty.  The  indications  of  difficulty 
include  taking  too  much  time  relative  to  the  norms  for  a  problem  and  making  too 
many  tests  of  low  power.  Possible  causes  of  low  diagnostic  productivity  include 
misinterpretation  or  misapplication  of  an  earlier  test  result  or  inability  to  identify  a 
test  that  has  potential  in  isolating  the  source  of  the  problem. 

Eliciting  (and  Refining)  a  Student's  Suspicions.  There  are  occasions 
during  training  when  assessment  of  student  actions  requires  knowing  the  student's 
beliefs  or  intentions.  The  major  means  of  ascertaining  the  student's  beliefs  about 
the  malfunction  state  is  to  use  the  IMTS  suspicion  eliciting  system.  The  student  is 
posed  a  number  of  questions  about  what  portions  of  the  device  he  or  she  suspects. 
The  student’s  responses  are  corrected  until  a  set  of  suspicions  has  been  agreed  upon 
that  is  correct  based  on  the  information  thus  far  available.  At  this  point  the  student 
and  IMTS  have  collaborated  to  identify  a  set  of  suspicions  that  make  sense,  given  the 
test  results  that  have  been  seen. 

This  process  relies  upon  a  representation  of  the  subject  device  as  a  hierarchy 
of  functional  subsystems.  In  the  case  of  the  helicopter  bladefold  system,  for 
example,  the  bladefolding  mechanism  was  analyzed  as  consisting  of,  first,  a 
hydraulic  and  an  electrical  subsystem.  Each  of  these  was  treated  as  having  a 
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number  of  major  descendent  subsystems,  and  so  on.  At  the  lowest  level  in  this 
analysis  are  particular  failures;  just  above  this  level  are  replaceable  components. 
This  analysis  of  the  higher  level  structure  of  the  device  is  similar  in  many  respects 
to  the  normative  student  model  created  with  the  knowledge  network  editor 
described  in  Section  III.  In  a  future  version  of  IMTS,  the  same  data  structure  will 
fill  both  roles  —  the  normative  knowledge  model  and  the  hierarchical  structure  of 
the  device  used  to  discuss  suspicions. 

The  first  time  that  a  student’s  suspicions  are  elicited,  the  IMTS  asks  whether 
the  student  suspects  any  of  the  highest  level  subsystems.  In  the  case  of  the  Bladefold 
system,  the  student  would  be  asked  whether  anything  should  be  suspected  in  the 
electrical  system  and  whether  anything  should  be  suspected  in  the  hydraulic  system. 
If  the  symptoms  obtained  by  the  student  justify  reducing  the  suspected  set  to  only 
one  of  the  subsystems,  then  the  process  of  eliciting  suspicions  continues  by 
inquiring  about  each  of  the  subsystems  of  that  system. 

Figures  15  and  16  present  the  suspicion  eliciting  system  of  IMTS  in  action.  The 
panel  in  Figure  15  lists  the  subsystems  that  should  be  considered  at  any  particular 
level  of  system  organization.  The  routine  steps  through  this  list,  highlighting  the 
subsystem  currently  in  question. 


No  —  the  GRIPE  doesn't  suggest  the  CHECK  BLAOEFOLO  CIRCUIT 


ELECTRICAL  SUBSYSTEM 


si 


HY0R/SERV0  SHUTOFF  SYSTEM 

ROTOR  BRAKE  SYSTEM 

ROTOR  HEAD  POSITIONING  SYSTEM 

BLADE  FOLD/SPREAD  SUBSYSTEM 

MISCELLANEOUS 

SAFETY  VALVE  CONTROL  CIRCUIT 

CHECK  BLAOEFOLO  CIRCUIT 

1 

ACCESSORY  ORIVE  CONTROL  CIRCUIT 

PYLON  UNLOCKED  CIRCUIT 

Figure  15.  A  Portion  of  the  IMTS  Suspicion  Eliciting  Mechanism 
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Figure  16  shows  the  student  being  asked  about  his  suspicion  of  the  Bladefold 
Power  Circuit,  and  being  shown  the  components  in  this  subsystem,  for  reference. 


Do  you  suspect  some  part  ot  the  BLADEFOLD  POWER 
CIRCUIT 


YES 


NO 


Bladefold  Master  Switch  (S24) 

Ne.  2  Fire  Emergency  Shut  Off  (S6) 

Feld  Power  On  Light  Bulb  (OS?) 

K101  A2/A3 
K106  A1/A2 
K10B  Coll 
K1B7  A1/A2 

Cable,  K107  A1  to  K104  A2 
K109  01/02 
Kill  A2/A3 

Cable,  Bladefold  Master  Switch  to  K109  01 

Cable,  K109  02  to  K112  Coll 

Cable,  Master  Switch  to  Kill  A3 

Cable,  Kill  A2  to  K107  A2 

Cable,  K107  A1  to  K115  A2 

K115  A2/A3 

Cable,  K115  A3  to  K101  A2 
Cable,  K101  A3  to  K108  A2 
Cable,  K106  A1  to  Fold  Power  On  Light 
Cable,  K10S  A1  to  Fold  Spread  Switch 
Circuit  Breaker  50 

Cable,  Circuit  Breaker  50  to  No. 2  Emergency  Shutoff  Switch 
Cable,  No. 2  Engine  Emergency  Shutoff  to  No. 2  Firewall  Valve 
No.  2  Engine  Firewall  Valve  Switch 

Cable.  No.  2  Enolne  Firewall  Valve  Switch  to  K1BB  Coil 


Figure  16.  The  Details  Panel  in  Suspicion  Eliciting 

The  IMTS  keeps  track  of  the  significance  of  tests  as  they  are  performed  by 
the  student,  remembering  which  suspected  elements  could  have  been  eliminated  by 
each.  It  can  therefore  tell  a  student  why  a  particular  element  should  no  longer  be 
suspected.  If  a  student  suspects  an  element  when  a  previously-conducted  test  should 
have  eliminated  it  from  suspicion,  then  IMTS  reminds  the  student  of  that  test  and 
the  value  it  revealed  (see  Figure  17).  Here  the  student  has  just  indicated  that  he 
suspects  the  Bladefold  Master  Switch.  IMTS  points  out  that  a  previously  seen  test 
result  iiould  have  eliminated  this  circuit  from  suspicion. 


No  —  Bladefold  Master  Switch  (S24)  was  eliminated  with  test  K101-A2  — 
value  of  test  was  28V-0C 


BIAOCFOU)  POWER  ORCUT 


Bladefold  Master  Switch  (S24) 


lo.  2  Fir©  Emergency  Shut  Off  (S6) 


I Fo 1 d  Power  On  Light  Bulb  (DS7) 
K101  A2/A3 


Figure  17.  Refining  Student  Suspicions 


Explaining  the  Meaning  of  the  Most  Recent  Test.  The  elicitation  and 
remediation  of  beliefs  about  possible  failures  considers  all  previous  tests  performed 
by  the  student  on  that  problem.  Sometimes  the  student  may  need  assistance  in 
interpreting  a  particular  symptom.  He  or  she  may  request  that  IMTS  interpret  the 
symptom  when  it  is  displayed. 


In  response  to  the  request,  the  IMTS  first  recapitulates  the  observation  and 
states  whether  the  observed  value  is  normal  or  abnormal.  Based  on  that  judgement, 
it  lists  the  subsystems  or  objects  that  should  still  be  suspected  and  those  that  should 
no  longer  be  suspected. 


The  voltage  at  K101-A2  was  28V  DC,  which  Is 
NORMAL,  so  we  now  know  that  the  following  components 
are  working  normally; 

Circuit  Breaker  80 
Accessory  Drive  Switch  (S51) 

Bladelold  Master  Switch  (S24) 

Kill  A2/A3 
K107  A1/A2 
K115  A2/A3 

Safety  Valve  Switch  (S25) 

K107  Coil 

Pylon  Lockpln  Limit  Switch  (S76) 

Pylon  Limit  Switch  (S77) 
and  associated  cables 

We  still  suspect  the  following: 

BLADEFOLD  POWER  CIRCUIT 
ACCESSORY  DRIVE  CONTROL  CIRCUIT 


Figure  18.  Explaining  Diagnostic  Test  Results 


Suggesting  Troubleshooting  Actions.  Sometimes  a  student  requires 
very  direct  assistance  in  proceeding  on  a  problem.  In  general,  this  could  be  termed 
a  ’planning’  skill,  although  in  diagnosis  the  scope  of  future  considerations  is 
normally  limited  to  just  identifying  the  next  best  action. 
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It  could  be  argued  that  in  such  a  case  the  student’s  instructor  should  be  notified 
so  that  the  student  can  receive  individual  attention  and  instruction.  In  those  cases  in 
which  instructor  time  is  largely  committed,  this  level  of  individualized  instruction 
may  be  difficult  to  guarantee.  Even  if  the  instructor  were  always  available, 
however,  it  is  likely  that  a  mandatory  interruption  in  the  student’s  practice  problem 
for  instructor  remediation  could  quickly  come  to  be  viewed  as  a  signal  of  failure. 

An  alternative  approach  is  to  provide  mechanisms  that  assure  that  the  student 
can  never  reach  a  complete  impasse.  Recent  research  (Fox,  1987)  suggests  that 
human  tutors  try  to  prevent  failure.  The  IMTS  approach  to  doing  this  on  the 
troubleshooting  task  is  to  provide  the  student  with  suggested  troubleshooting 
actions  that  are  guaranteed  to  be  useful  and  rational  (and  are  actually  near-optimal). 
Figure  19  shows  the  form  of  such  advice. 

Measure  the  voltage  at  K101-A2 
28V-OC  would  be  normal. 

If  normal,  the  failure  is  one  of: 

K101  A2/A3 
K106  A1/A2 
K106  Coil 

Fold  Power  On  Light  Bulb  (DS7) 

Circuit  Breaker  50 

No.  2  Engine  Firewall  Valve  Switch 

No.  2  Fire  Emergency  Shut  Off  (S6) 

Linear  Actuator 
and  associated  cables 

If  abnormal,  the  failure  Is  one  ol: 

Circuit  Breaker  80 
Accessory  Drive  Switch  (S51) 

Safety  Valve  Switch  (S25) 

Bladelold  Master  Switch  (S24) 

Pylon  Limit  Switch  (S77) 
kill  A2/A3 
K107  A1/A2 

Pylon  Lockpin  Limit  Switch  (S76) 

K115  A2/A3 
K107  Coil 

and  associated  cables 

Figure  19.  Generated  Troubleshooting  Suggestions 

By  exploring  the  fault-effect  data,  following  each  test  performed  by  the 
student,  Profile  identifies  the  next  test  that  will  best  discriminate  among  the  current 
suspicions.  This  process  is  done  whether  or  not  the  student  requests  assistance.  If 
the  student  proceeds  without  getting  help,  then  Profile  simply  compares  the 
student's  test  to  its  own  selection,  to  yield  a  test  power  measure.  If  the  student 
requests  assistance  in  proceeding,  then  Profile  presents  and  explains  its  selection. 
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Between-problem  Instruction 


Because  a  fault  isolation  exercise  involves  an  unknown  to  be  discovered  by  the 
student,  the  IMTS  attempts  to  defer  some  remediations  and  explanations  —  those 
that  would  destroy  the  value  of  the  problem  —  until  after  the  problem  has  been 
completed.  At  that  time,  a  number  of  choices  are  offered  for  further  exploring  the 
now-known  failure,  as  shown  in  Figure  20. 


What  do  you  want  to  do  next' 


Sec  Expert  Solution 


Replay  Student  Solution 


IMTS  Simulation 


Go  On  To  Next  GMTS  Problem 


Slop  Session 


Figure  20.  The  Student’s  Choices  Between  Problems 

These  choices  include  two  instructional  options  that,  like  those  already 
discussed,  make  use  of  the  Profile  analysis  of  the  troubleshooting  context: 
presentation  of  an  expert  solution  and  a  critiqued  replay  of  the  student’s  solution. 

Expert  Troubleshooting  of  the  Same  Problem.  The  IMTS  describes 
each  action  that  Profile  dictates  for  troubleshooting  the  reported  fault  and  it 
interprets  the  results  that  would  be  seen  for  each.  The  interpretation  lists  the 
elements  eliminated  from  suspicion  by  the  test  and  those  for  which  suspicion  should 
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increase  as  a  result  of  the  test.  Figure  21  shows  the  start  of  such  an  expert  solution 
of  a  problem. 

Fold  Power  On  Light  does  not  come  on  when  Master  Switch 
is  placed  On.  The  system  is  in  Accessory  Drive  with  blades 
spread.  In  order  to  carry  out  tests  for  this  complaint;  1. 

Ensure  that  the  Safety  Valve  Switch  is  "OPEN."  2.  Ensure 
that  the  Master  Switch  is  On.  3.  Ensure  that  the  Pylon  is 
spread  and  locked. 

I  will  measure  the  voltage  at  K101-A2 

The  voltage  at  K101-A2  was  28V -DC,  which  is 
NORMAL,  so  we  now  know  that  the  following  components 
are  working  normally: 

Circuit  Breaker  80 
Accessory  Drive  Switch  (S51) 

Bladefold  Master  Switch  (S24) 

Kill  A2/A3 
K107  A1/A2 
K115  A2/A3 

Safety  Valve  Switch  (S25) 

K107  Coil 

Pylon  Lockpln  Limit  Switch  (S76) 

Pylon  Limit  Switch  (S77) 
and  associated  cables 

I  still  suspect  the  following: 

BLADEFOLD  POWER  CIRCUIT 
ACCESSORY  DRIVE  CONTROL  CIRCUIT 

Figure  21 .  Presentation  of  a  Generated  Expert  Troubleshooting  Sequence 

Debriefing  the  Student  with  a  Problem  Replay.  Another  option 
offered  to  students  at  the  end  of  a  troubleshooting  problem  is  to  review  their  own 
sequence  of  actions,  with  generated  commentary.  This  presentation  describes  what 
the  student  should  have  learned  from  each  test  that  was  performed,  and  identifies 
tests  that  had  no  value  in  the  context  of  the  troubleshooting  sequence  followed.  See 
Figure  22. 

Fold  Power  On  Light  does  not  come  on  when  Master  Switch 
is  placed  On.  The  system  is  in  Accessory  Drive  with  blades 
spread.  In  order  to  carry  out  tests  lor  this  complaint:  1. 

Ensure  that  the  Safety  Valve  Switch  is  "OPEN."  2.  Ensure 
that  the  Master  Switch  Is  On.  3.  Ensure  that  the  Pylon  is 
spread  and  locked. 

Next,  you  set  the  Electric/Hydraulic  Power 
switch  to  On 

Next,  you  set  the  Safety  Valve  Switch  (S25) 
switch  to  Open 

Next,  you  set  the  Master  Switch  (S24) 
switch  to  On 

Observing  the  Fold  Power  On  Light  Bulb  did  not  provide 
any  Information  that  couldn’t  be  figured  out  from  the 
original  symptoms. 

Figure  22.  Problem  Replay  with  Generated  Commentary 
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SECTION  V.  CONCLUSIONS 
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Findings  and  Recommendations 

In  the  course  of  this  research  and  development  project,  we  have  explored  a 
number  of  alternative  approaches  to  simulation,  student  monitoring,  problem 
selection,  and  student  aiding.  In  addition  to  the  techniques  presented  here,  other 
less  successful  approaches  were  developed,  evaluated,  and  discarded.  To  share  both 
the  successes  and  failures,  we  present  the  following  conclusions. 

Device  models  for  simulation-based  diagnostic  training  should 
support  quantitative  modeling.  To  some  extent,  the  object  behavior  rules  in 
the  IMTS  appear  qualitative.  For  example,  a  typical  rule  states  that  something 
i  happens  when  a  value  at  one  port  is  larger  than  the  value  at  another  port.  This  type 

!  of  expression  is  effective  because  that  is  the  way  the  object  actually  behaves.  In 

other  cases  objects  respond  to  the  values  at  ports.  For  example,  certain  pressure 
valves  change  state  when  the  pressure  exceeds  some  characteristic  value. 
Furthermore,  to  correctly  determine  how  resistive  parts  will  behave  in  an  electrical 
circuit,  it  is  necessary  to  keep  track  of  very  precise  values  within  the  circuit.  As  a 
result,  the  IMTS  simulation  program  is  essentially  quantitative. 

It  is  tempting  to  develop  a  simulation  composition  system  that  does  not  require 
that  accurate  quantitative  values  be  passed  from  one  object  to  another.  At  first 
blush,  it  appears  that  both  the  authoring  of  object  behaviors  and  the  simulation 
driver  software  can  be  made  simpler  by  using  a  qualitative  or  'fuzzy'  quantitative 
approach.  Unfortunately,  when  objects  pass  imprecise  values,  two  serious 
problems  arise  in  the  simulation.  First,  it  becomes  awkward  or  impossible  to 
|  provide  simulated  test  equipment.  Special-purpose  simulated  test  equipment  must 

I  be  constructed  that  translates  inaccurate  or  non-quantitative  values  and  converts 

|  them  into  the  nominal  values  expected  in  the  device.  This  would  be  necessary  if  the 

j  student  is  to  be  able  to  practice  interpreting  quantitative  readings  back  to  qualitative 

judgements  such  as  "normal"  or  "high". 

Second,  in  complex  devices,  it  becomes  difficult  or  impossible  to  avoid 
incorrect  device  responses,  owing  to  inaccuracies  in  internal  effects.  In  summary, 

36 


i 


A 


simulations  of  complex  systems  tend  not  to  work  when  the  underlying  model  is 
approximate. 

This  is  in  no  way  intended  to  minimize  the  fascinating  work  being  done  with 
qualitative  models.  We  simply  find  that  complex  models  may  not  respond  correctly 
when  they  operate  upon  approximate  values.  Further  this  finding  does  not  suggest 
that  human  diagnosticians  operate  quantitatively.  In  fact,  the  quantitative 
manipulations  that  the  IMTS  simulation  program  performs,  to  maintain  the 
graphical  simulation,  are  not  apparent  to  the  student. 

Visual  representations  must  not  be  tightly  linked  to  the  device 
model.  Instructors  and  simulation  developers  need  to  be  able  to  make  simplified 
presentations  that  do  not  involve  every  element  in  the  real  device.  Yet,  if  the 
graphical  objects  can  obtain  their  behaviors  only  from  their  own  underlying 
functional  behavior  rules,  then  every  component  would  have  to  be  included.  This 
awkward  restriction  led  to  the  development  of  the  feature  that  allows  physical 
simulations  and  simplified  simulations  to  obtain  their  behaviors  from  objects  in  the 
functional  model. 

Advice  does  not  have  to  be  optimal,  but  it  must  be  rational.  One 

of  the  most  important  aspects  of  successful  training  using  computer-generated 
materials  is  maintaining  the  trust  and  confidence  of  the  learner.  For  complex 
systems,  slight  non-optimalities  in  advice  are  very  unlikely  to  be  noticed  in  the 
course  of  a  single  student's  instruction.  In  fact,  moderate  non-optimalities  are 
scarcely  a  matter  of  concern,  since  even  excellent  human  tutors  are  significantly 
non-optimal  in  the  troubleshooting  strategies  they  demonstrate.  On  the  other  hand, 
irrational  advice  is  devastating  to  student  confidence.  It  is  much  better  for  an 
artificial  instructor  to  remain  silent  than  to  risk  offering  truly  questionable  advice. 

Assessment  of  student  performance  must  be  accurate  and  based 
upon  very  recent  performance.  It  is  frustrating  for  a  student  who  has  been 
struggling,  but  who  has  just  seen  the  light  and  begun  to  make  progress  in  a  problem, 
to  suddenly  be  interrupted  with  unwanted  admonitions  and  instruction.  It  is 
probably  better  to  err  on  the  side  of  too  few  interruptions  than  to  interrupt 
excessively.  Further,  it  has  been  found  crucial  to  only  consider  very  recent 
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performance,  in  deciding  when  to  intervene,  as  lengthy  moving  averages  can 
trigger  interruptions  even  when  the  student  has  just  corrected  course,  and  is  on  the 
way  to  a  solution. 

Accurate  tracking  of  the  student  conflicts  with  the  goal  of  a 
transparent  and  efficient  practice  environment.  Many  of  the  actions  that 
students  take  could  have  several  different  rational  motivations.  The  number  of 
irrational  motivations  for  a  test  or  replacement  is  unbounded.  In  order  to  really 
know  what  the  student  intends,  it  is  probably  necessary  to  ask.  Unfortunately, 
constantly  harassing  the  student  with  demands  that  every  action  be  justified  in  detail 
radically  changes  the  nature  of  the  troubleshooting  task  (and  makes  it  very 
unpleasant).  A  balance  must  be  sought  to  ensure  effective  training,  and  the  artificial 
instructor  must  always  be  aware  that  its  model  of  student  intent  is  probably 
imperfect. 

The  need  to  ask  the  student  about  beliefs  or  intentions  was  part  of  the 
motivation  for  the  development  of  the  suspicion  eliciting  system  used  in  IMTS. 
Further  work  is  underway  to  reduce  the  intrusiveness  of  this  process,  so  that  it  can 
be  used  more  often.  This  will  make  it  possible  to  track  student  intent  more  closely 
without  damaging  the  natural  troubleshooting  process. 

Parameters  currently  used  to  manage  instruction  are  arbitrary. 

In  the  present  system,  interventions  are  based  upon  accurate  computations  of 
student  performance,  compared  to  quite  arbitrary  threshold  values  (such  as 
inactivity  exceeding  three  minutes,  or  two  irrational  tests  in  a  row).  Ideally,  a 
science  of  instruction  would  serve  as  the  basis  for  determining  the  appropriate 
parameters  for  making  decisions  about  instructional  intervention. 

Precomputing  of  fault  effects  is  necessary.  For  a  very  complex 
device,  a  single  fault  can  have  many  effects.  To  discriminate  among  possible  faults, 
all  the  effects  of  each  fault  must  be  computed.  Although  we  have  made  very 
significant  improvements  in  simulation  speed  by  aggressively  pursuing  that  goal, 
computed  simulations  cannot  be  made  instantaneous.  Where  a  large  number  of 
faults  must  be  considered,  each  with  a  significant  number  of  effects,  precomputing 
these  effects  is  essential  to  providing  advice  to  students  in  a  timely  fashion. 
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The  Next  Steps  for  Enhancing  Training  in  IMTS 


IMTS  represents  a  powerful  environment  for  producing  and  delivering 
interactive  simulation  training.  It  also  constitutes  a  promising  foundation  on  which 
to  build  an  even  more  capable  technical  training  system.  Here  we  briefly  touch  on 
the  features  to  be  implemented  in  the  near  future. 

Simulation  of  Partially  Specifiable  Systems.  Some  equipment 
systems,  such  as  Bladefold,  lend  themselves  to  simulation  based  on  detailed 
descriptions  at  the  component  level.  This  level  of  description  is  appropriate  when 
the  number  of  low-level  components  (such  as  relay  contact  sets,  switches,  lights, 
and  pressure  snubbers)  is  not  so  large  that  it  is  infeasible  to  draw  them,  describe 
their  behaviors,  and  specify  their  connections.  This  is  the  way  that  the  IMTS 
Bladefold  simulation  has  been  implemented. 

Other  equipment  systems  are  much  too  large  and  complex  to  be  described  in  a 
similar  manner,  as  too  much  time  would  be  required  to  produce  detailed  behavior 
descriptions  of  every  component.  An  alternative  approach,  capable  of  providing 
training  for  devices  of  arbitrary  complexity,  is  required.  For  such  complex 
systems,  IMTS  will  make  use  of  system  level  descriptions  instead  of  component 
level  descriptions. 

In  both  approaches  to  IMTS  simulation  training,  the  aiding  and  instructional 
features  are  based  on  the  Profile  system's  analysis  of  fault  effect  data.  In  the  case  of 
simulations  based  on  detailed  component  descriptions,  this  fault  effect  information 
is  generated  automatically  from  the  'deep'  device  model.  In  the  case  of  simulations 
based  on  system-level  descriptions,  a  subject  matter  expert  generates  the  fault  effect 
data.  For  the  latter  type  of  IMTS  simulations,  the  fault  effect  data  are  used  to  drive 
the  simulation  of  the  target  equipment.  For  the  former  type,  the  simulation  is 
generated  by  a  device  model  based  on  detailed  descriptions  of  the  behavior  of  the 
device’s  components  (see  Figure  23). 


IMTS  Based  on  System  Level  Descriptions 


Figure  23.  Two  IMTS  Approaches  to  Device  Representation  &  Training 

Authored  Procedure  Training.  Instructors  will  be  able  to  create  guided 
simulations  for  teaching  particular  procedures.  The  authoring  process  will  consist 
of  putting  a  graphical  simulation  into  record  mode,  and  then  carrying  out  the  set  of 
actions  that  they  want  to  require  their  students  to  perform.  Authors  will  also  have 


the  option  of  entering  small  blocks  of  text  that  can  appear  at  specified  points  in  the 
sequence  of  actions  they  record. 


During  the  procedure  training,  students  see  the  text  blocks,  which  describe 
what  is  required  of  them.  When  a  student  performs  a  required  action,  the 
simulation  updates  and  the  next  text  block  is  presented.  If  the  student  performs 
some  action  other  than  the  scripted  (recorded)  one,  then  the  required  action  will  be 
graphically  highlighted. 

The  same  methods  will  be  applicable  to  other  training  requirements  in 
addition  to  procedure  training.  For  example,  ad  hoc  instructional  elements  will  be 
easily  authored  using  the  simulation  record  mode.  Instructors  who  wish  to  teach  a 
particular  approach  to  troubleshooting  a  certain  fault  will  be  able  to  record  the 
sequence  of  actions  they  use  to  troubleshoot  the  fault,  adding  explanatory  text  as 
they  go.  In  the  simulation  playback  mode,  students  will  be  guided  to  perform  the 
same  troubleshooting  steps. 
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